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METHODS AND APPARATUS FOR RECOVERING WORK OF 
ONE COMPUTER BY ANOTHER COMPUTERS 



BACKGROUND OF THE INVENTION 

The present invention relates to techniques 
of recovering a process at a data center when a failure 
occurs at another data center during the execution of 
5 the process. 

In a conventional recovery system (a recovery 
system intended to recover the system) such as an on- 
line system of banking facilities^ synchronously when 
data is renewed, a backup of data is obtained not to 
10 lose data or to reduce data loss. 

A high speed and automatic recovery method 
and system for recovering a computer work load has been 
proposed- This conventional recovery method comprises 
steps of: expressing requirements of a computer system, 
15 associated networking and peripheral apparatuses; 

allowing a customer to designate a recovery command; 
processing the recovery command at a recovery site; and 
utilizing a computer to process the recovery command, 
to assign resources at the recovery site and to 
20 reconfigure the computer system. The recovery process 
is automatically performed by matching the system 
requirements with available resources. (For example, 
refer to JP-A-2001-265726 . ) 

Since a conventional recovery system aims at 
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no data loss, it is necessary to adopt the recovery 
system of no data loss and high cost. 



SUMMARY OF THE INVENTION 

It is an object of the invention to provide 
5 the technique which can meet the needs for a relatively 
loose recovery of data still not backed up at the time 
of a failure by later inputting it (e.g., manually) and 
by acquiring a backup of data regularly (e.g., once per 
day) - 

10 According to the invention, in a disaster 

recovery system for recovering a process at a data 
center when a failure occurs at another data center 
during execution of the process, the recovery process 
is performed by an information processing apparatus 

15 whose necessary recovery time including a time taken to 
input data still not backed up satisfies a 
predetermined requested recovery time. 

In the disaster recovery system of the 
invention, first, data at a first data center normally 

20 used by an end user is transmitted regularly to a 

second data center at a predetermined time interval and 
a backup of the received data is formed at the second 
data center. 

When a failure occurs at the first data 

25 center and the end user cannot use the application at 
the first data center, an information processing 
apparatus whose necessary recovery time including a 



time taken to input data still not backed up satisfies 
a predetermined requested recovery time is selected 
from information processing apparatuses in the second 
data center. 

5 When a specific information processing 

apparatus is selected from information processing 
apparatuses in the second data center, the application 
used at the first data center is deployed in the 
selected information processing apparatus and the data 

10 at the first data center is recovered from the backup 
data formed in the second data center at the selected 
specific information processing apparatus to thereby 
recover the process at the first data center. 

As above, according to the disaster recovery 

15 system of the invention, it is possible to meet the 

needs for a relatively loose recovery of data still not 
backed up at the time of a failure by later inputting 
it. 

Other objects, features and advantages of the 
20 invention will become apparent from the following 

description of the embodiments of the invention taken 
in conjunction with the accompanying drawings. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagram illustrating a normal 
25 operation before a failure occurs at a Tokyo data 
center (DC) according to an embodiment . 

Fig. 2 is a diagram showing an outline 
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structure of a DC management server 14 0 of the 
embodiment . 

Fig. 3 is a diagram illustrating a backup 
data transfer from the Tokyo DC to an Osaka DC during a 
5 normal operation according to the embodiment. 

Fig. 4 is a diagram illustrating the summary 
of selection of a recovery server at the Osaka DC^ 
deployment of an application, and recovery by backup 
data when a failure occurs at the Tokyo DC according to 
10 the embodiment. 

Fig. 5 is a diagram illustrating an input of 
data still not backed up after the recovery by the 
backup data according to the embodiment. 

Fig. 6 is a diagram illustrating the summary 
15 of a process of continuing an operation of an end user 
by switching to the Osaka DC after the completion of 
the recovery according to the embodiment. 

Fig. 7 is a flow chart illustrating a process 
of selecting a server to be used for recovery according 
20 to the embodiment. 

Fig. 8 is a diagram showing an example of an 
application information table 208 according to the 
en±)odiment . 

Fig. 9 is a diagram showing an example of a 
25 server list table 209 according to the embodiment - 

Fig. 10 is a diagram illustrating the normal 
operation by a plurality of end users at the Tokyo DC 
according to the embodiment. 
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Fig. 11 is a diagram showing an example of a 
user priority level table 210 according to the 
embodiment . 

Fig. 12 is a diagram showing an example of 
5 the result of recovery at the Osaka DC when a failure 
occurs at the Tokyo DC used by a plurality of end users 
according to the embodiment - 



DESCRIPTION OF THE EMBODIMENT 

An embodiment of a disaster recovery system 

10 will be described which recovers a process at a data 
center (DC) when a failure occurs at another DC while 
executing the process. 

Fig. 1 is a diagram illustrating the normal 
operation before a failure occurs at a Tokyo DC 

15 according to the embodiment- As shown in Fig. 1, in 
the disaster recovery system of this embodiment, the 
Tokyo DC or first DC used by a computer of an end user 
and an Osaka DC or second DC used during a failure of 
the Tokyo DC are interconnected by a network. During 

20 the normal operation, an end user utilizes applications 
111 and 112 at the Tokyo DC. 

Fig. 2 is a diagram showing the outline 
structure of a DC management server 140 according to 
the embodiment. As shown in Fig. 2, the DC management 

25 server 140 of this embodiment has a CPU 201, a memory 
202, a magnetic disk device 203, an input device 204, 
an output device 205, a CD-ROM device 206, a 



communication device 207, an application information 
table 208, a server list table 209, and a user priority 
level table 210. 

CPU 201 is a device for controlling the whole 
5 operation of the DC management server 140. The memory 
202 is a storage device in which various programs and 
data necessary for controlling the whole operation of 
the DC management server 14 0 are loaded. 

The magnetic disk device 203 is a storage 

10 device for storing the various programs and data. The 
input device 204 is used for entering various inputs 
necessary for the recovery of the Tokyo DC. The output 
device 205 is used for sending various outputs 
necessary for the recovery of the Tokyo DC. 

15 The CD-ROM device 206 is a device for reading 

the contents of a CD-ROM in which the various programs 
are recorded. The communication device 207 is a device 
for communicating with other information processing 
apparatuses such as the Tokyo DC and an end user via a 

20 network such as the Internet and an intranet. 

The application information table 208 is a 
table for storing information of applications to be 
used by an end user. The server list table 209 is a 
table for storing the list of servers available for the 

25 recovery- The user priority level table 210 is a table 
for storing information of a priority level of each 
user . 

The DC management server 140 has also a 



backup forming unit 211, a server selecting unit 212 
and a recovery unit 213. 

The backup forming unit 211 receives 
application data 130 at the Tokyo DC used by an end 
5 user in the normal operation at a predetermined time 
interval to make backup data 170 of the application 
data 130 at the Osaka DC. The backup forming unit 211 
adjusts a time interval of the backup in order to make 
a necessary recovery time to be later described satisfy 

10 a predetermined requested recovery time. 

The server selecting unit 212 is an 
information processing apparatus selecting unit for 
selecting a server or servers whose necessary recovery 
time satisfies the predetermined requested recovery 

15 time, from servers 161 to 163 at the Osaka DC. The 
necessary recovery time includes: a time taken to 
deploy applications 151 and 152 same as applications 
111 and 112 used at the Tokyo DC in the Osaka DC; a 
time taken to recover data from the backup data 170 at 

20 the Osaka DC; and a time taken to input data still not 
backed up to the Osaka DC, respectively when a failure 
occurs at the Tokyo DC. 

The recovery unit 213 deploys the 
applications 151 and 152 same as the applications 111 

25 and 112 used at the Tokyo DC in the selected server or 
servers, and recovers the application data 130 at the 
Tokyo DC from the backup data 170 at the selected 
server or servers. 
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The programs for making the DC management 
server 140 function as the backup forming unit 211, 
server selecting unit 212 and recovery unit 213 are 
assumed to be recorded in a recording medium such as a 
5 CD-ROM, loaded in a magnetic disk or the like, loaded 
in the memory and executed. The storage medium for 
recording the programs may be another recording medium 
different from a CD-ROM. The programs may be installed 
from the recording medium into an information 

10 processing apparatus, or may be accessed via a network 
to execute them. 

If the Tokyo DC makes a backup, the DC 
management server 100 at the Tokyo DC performs the 
processes similar to those of the DC management server 

15 140 described above. 

Fig. 3 is a diagram illustrating an operation 
of transferring backup data from the Tokyo DC to the 
Osaka DC during the normal operation. As shown in Fig. 
3, the Osaka DC the backup forming unit 211 of the DC 

20 management server 140 receives the application data 130 
at the Tokyo DC used by an end user during the normal 
operation at a predetermined data transfer interval and 
makes the backup data 170 of the application data 130. 
In this case, the backup forming unit 211 of the DC 

25 management server 140 at the Osaka DC issues a transfer 
request for the application data 130 to the DC 
management server 100 at the Tokyo DC at the 
predetermined data transfer interval. Instead, the 



backup forming unit 211 may adjust the data transfer 
interval for the backup in such a manner that the 
necessary recovery time satisfies the predetermined 
requested recovery time in the application information 
5 table 208. 

Fig. 4 is a diagram showing the outline of 
selection of a recovery server at the Osaka DC, 
deployment of an application, and recovery of backup 
data to be performed when a failure occurs at the Tokyo 

10 DC. As shown in Fig. 4, in the disaster recovery 

system of this embodiment, when a failure occurs at the 
Tokyo DC, recovery servers are selected from the 
recovery servers 161 to 163 at the Osaka DC, the 
applications 151 and 152 are deployed, and the 

15 application data 130 is recovered from the backup data 
170. 

Fig. 5 is a diagram illustrating a process of 
inputting data still not backed up after the recovery 
of the backup data according to the embodiment. As 

20 shown in Fig. 5, in the disaster recovery system of the 
embodiment, after the failure occurs at the Tokyo DC 
and the application data 130 is recovered from the 
backup data 170 at the Osaka DC, the data still not 
backed up and input to the Tokyo DC during the period 

25 after the previous backup and before the failure 
occurrence, is input to the Osaka DC from an 
information processing apparatus of the end user. 

Fig. 6 is a diagram showing the outline of 
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the process of continuing the operation of the end user 
after the recovery completion and switching to the 
Osaka DC according to the embodiment. As shown in Fig. 
6, in the disaster recovery system of this embodiment, 
5 after the data still not backed up from the information 
processing apparatus of the end user is input to the 
Osaka DC and the recovery at the Osaka DC is completed, 
use of the applications by the information processing 
apparatus of the end user is switched from the Tokyo DC 

10 to the Osaka DC to continue the operation by using the 
applications . 

Fig. 7 is a flow chart illustrating a process 
of selecting a server available to the recovery 
according to the embodiment- As shown in Fig. 7, the 

15 server selecting unit 212 of the DC management server 
140 selects a server or servers whose necessary 
recovery time satisfies the predetermined requested 
recovery time, from the servers 161 to 163 at the Osaka 
DC. The necessary recovery time includes: a time taken 

20 to deploy the applications 151 and 152 same as 

applications 111 and 112 used at the Tokyo DC in the 
Osaka DC; a time taken to recover data from the backup 
data 170 at the Osaka DC; and a time taken to input 
data still not updated to the Osaka DC, respectively 

25 when a failure occurs at the Tokyo DC. 

The recovery unit 213 of the DC management 
server 140 deploys the applications 151 and 152 same as 
the applications 111 and 112 used at the Tokyo DC in 



the selected server or servers, and recovers the 
application data 130 at the Tokyo DC from the backup 
data 170 at the selected server or servers. 

The end user utilizes the Tokyo DC during the 
5 normal operation as shown in Fig. 1, and backup data is 
transferred from the Tokyo DC to Osaka DC at the 
predetermined time interval as shown in Fig. 3. When a 
failure occurs at the Tokyo DC as shown in Fig. 4, the 
Osaka DC selects the servers available to the recovery 

10 and deploys the applications in the selected servers 
and recovers the data from the backup data. 

More specifically, first at Step 701 the 
server selecting unit 212 of the DC management server 
140 refers to the application information table 208 to 

15 read a data generation frequency and a data transfer 
interval corresponding to the application used at the 
Tokyo DC and substitute a product thereof for a 
variable A. 

Fig. 8 is a diagram showing an example of the 
20 application information table 208 according to the 
embodiment- As shown in Fig. 8, the application 
information table 208 stores information of 
applications to be used by an end user. 

Referring to Fig. 8, an input time is a time 
25 taken to input one data set of the application at the 
information processing apparatus of an end user. A 
data transfer time interval is a time interval in which 
data necessary for forming a backup of the application 
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data 130 of the application is transmitted. A data 
generation frequency is the number of updated data sets 
per unit hour necessary for using the application. A 
deploy time is a time taken to deploy the application 
5 in the standard server having a deploy time ratio (to 
be described later) of "1". 

The requested recovery time is a user 
permitted time from a failure occurrence to the 
recovery completion of the application process. The 

10 server selecting unit 212 receives a designated 

permitted time when the application process starts^ 
from the information processing apparatus of an end 
user, and sets the received permitted time to the 
application information table 208 as the requested 

15 recovery time. 

A priority level is a priority level of the 
application among a plurality of applications used by 
an end user. An optional number of additional items 
may be used. For example, the additional item may be 

20 the performance information or the like of the server 
requested by the application during the operation, and 
upon occurrence of a failure at the Tokyo DC, the 
server satisfying the performance information is 
selected. 

25 Next, at Step 702 the server selecting unit 

212 refers to the application information table 208 to 
read the input time of the data corresponding to the 
application used at the Tokyo DC and substitute it for 



a variable B - 

At Step 703 the server selecting unit 212 
refers to the server list table 209 to search the 
record of a server which can execute the application 
5 used at the Tokyo DC, i.e., the record of a server 

having the name corresponding to the application used 
at the Tokyo DC in a use field of the server list table 
209. 

Fig. 9 is a diagram showing an example of the 
10 server list table 209 according to the embodiment- As 
shown in Fig. 9, the application information table 208 
stores the list of servers 161 to 163 usable at DC for 
the recovery process. 

Referring to Fig. 9, ID represents a unique 
15 name for identifying each of the servers 161 to 163 at 
DC. In the use field, it is assumed that a plurality 
of a list of applications which the server can execute 
are listed. 

A deploy time ratio is a relative value of a 
20 deploy time relative to a deploy time of the standard 
server taken to deploy the application. The deploy 
time of the standard server in the application 
information table 208 multiplied by the relative value 
is the time taken to deploy the application by the 
25 server. 

A data recovery time ratio is a relative 
value of a data recovery time relative to a data 
recovery time taken to recover the data from the backup 



data 170. The recovery time per unit size taken by the 
standard server and multiplied by the relative value 
and the size of the backup data 170 is the time taken 
to recover the data from the backup data 17 0 by the 
5 server- An optional number of additional items may be 
used. For example, the additional item may be the 
performance information or the like of the server 
requested by the application during the operation, and 
upon occurrence of a failure at the Tokyo DC, the 
10 server satisfying the performance information is 
selected. 

Next, at Step 704 the server selecting unit 
212 refers to the application information table 208 to 
read the deploy time of the application used at the 

15 Tokyo DC. Thereafter, the deploy time ratio of the 
server searched at Step 703 is read from the server 
list table 209. A product of the deploy time and the 
deploy time ratio is substituted for a variable C. 

At Step 705 the backup data 170 is accessed 

20 to acquire the size of the backup data of the 

application. Thereafter, the data recovery time ratio 
of the server searched at Step 703 is read from the 
server list table 209. A product of the backup data 
size, the recovery time per unit size by the standard 

25 server, and the data recovery time ratio is substituted 
for a variable D. 

At Step 706 by referring to the application 
information table 208, the requested recovery time 



corresponding to the application used at the Tokyo DC 
is read. A product of the values of the variables A 
and B added with the values of the variables C and D is 
compared with the read requested recovery time, 
5 The product of the values of the variables A 

and B corresponds to the time taken to input the data 
still not backed up and generated before the next data 
transfer time, to the Osaka DC. The value of the 
variable C corresponds to the time taken to deploy the 

10 application in the server. The value of the variable D 
corresponds to the time taken to recover the backup 
data of the application by the server- When the value 
of the variable A is to be calculated at Step 701, 
instead of using the data transfer interval, a lapse 

15 time from the preceding backup execution time may be 
used to use the data generated during the lapse time 
from the preceding backup execution time as the data 
still not backed up. 

If the comparison result at Step 706 

20 indicates that the addition result is shorter than the 
requested recovery time, the server searched at Step 
703 is used as the server at the Osaka DC for the data 
recovery to complete the server selecting process for 
the application. If not, the flow returns to Step 703 

25 whereat another candidate server is searched. 

It there are a plurality of applications used 
at the Tokyo DC, the processes from Step 701 to Step 
706 are repeated necessary times to select servers 



other than the already selected server as the servers 
to be used for the data recovery. 

Thereafter, an application is deployed in 
each selected server in the manner similar to that 
5 described above and the data is recovered from the 

backup data. Thereafter, the data still not backed up 
is entered as shown in Fig. 5 and the end user 
continues the process by switching to the Osaka DC as 
shown in Fig. 6. 

10 According to the embodiment described above, 

the recovery process is performed by selecting a server 
whose necessary recovery time including the time 
necessary for entering data still not backed up 
satisfies the predetermined requested recovery time. 

15 For example, if the data to be dealt with has less 
urgency and a small number of renewal occurrence 
frequencies, such as resident card data of a local 
self-governing body, data still not backed up when a 
failure occurs is input manually for the data recovery. 

20 A relatively loose recovery process can therefore be 

permitted and a disaster recovery system of a low cost 
can be provided. 

Next, in the recovery system of this 
embodiment, another process will be described in which 

25 a serve is selected from the servers 161 to 163 at the 
Osaka DC in the order of a higher priority level of an 
application or an end user among a plurality of end 
users . 
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Fig. 10 is a diagram illustrating the normal 
operation while a plurality of end users utilize the 
Tokyo DC according to the embodiment- In the example 
shown in Fig. 10, information processing apparatuses of 
5 end users A and B and the Tokyo DC and Osaka DC are 
interconnected by the network. 

The end users A and B utilize a plurality of 
applications at the Tokyo DC during the normal 
operation, and backup data is transferred to the Osaka 

10 DC at a predetermined time interval. 

When a failure occurs at the Tokyo DC, the 
server selecting unit 212 of the Osaka DC calculates a 
difference between priority levels of a plurality of 
applications used at the Tokyo DC. In this case, the 

15 priority order of each application used at DC for the 

recovery process is decided by using as the calculation 
parameters the priority level (a priority level of an 
application used by each end user) in the application 
information table 208 and the priority level (a 

20 priority level of an end user utilizing DC) in the user 
priority level table 210. 

Fig. 11 is a diagram showing an example of 
the user priority table 210 of the embodiment- As 
shown in Fig. 11, the user priority level table 210 

25 stores information representative of the priority level 
of each user. By using the value of the priority level 
stored in this table and the value of the priority 
level stored in the application information table 208, 



the priority order of each application at DC is 
decided- 

For example, in accordance with the 
" [priority level of an application used by an end user] 
5 X [priority level of the end user] , the priority order 
of the application is decided for the recovery process 
at the Osaka DC. Other calculation methods may also be 
incorporated. Without using the user priority level 
table 209, the priority level of each user's 
10 application for the recovery process at DC may be 

directly stored in the application information table 
208- 

In the order of a higher priority level 
determined in this manner, the server selecting process 

15 illustrated in Fig. 7 is executed so that the disaster 
recovery with a priority level can be realized- Fig. 
12 shows an example of the result of an actual recovery 
process executed in this manner. 

Fig. 12 is a diagram showing an example of 

20 the recovery result at the Osaka DC after a failure 
occurs at the Tokyo DC used by a plurality of end 
users. In the example shown in Fig. 12, the end user B 
has a higher priority level than that of the end user A 
and the application Al used by the end user A has a 

25 higher priority level than that of the application A2 . 
Because of these priority orders, the application A2 is 
not subjected to the recovery process at the Osaka DC 
having an insufficient number of servers. 
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In the disaster recovery system of the 
embodiment described above, when a failure occurs, the 
application having a low priority level is not 
subjected to the recovery process and waits for the 
5 recovery of the Tokyo DC. Needs for such a relatively 
loose recovery can be met . 

In the recovery system of this embodiment, if 
there is an application not subjected to the recovery 
process, information of the application may be notified 

10 to another DC to inquire the DC management server of 
the other DC about whether or not the recovery is 
possible. If the recovery is possible, the backup data 
for the application is transferred to the other DC to 
perform the recovery process. 

15 As described above, in the disaster recovery 

system of the embodiment, the recovery process is 
performed by selecting an information processing 
apparatus whose necessary recovery time including the 
time necessary for entering data still not backed up 

20 satisfies the predetermined requested recovery time. 
It is therefore possible to meet the needs for a 
relatively loose recovery of data still not backed up 
at the time of a failure by later inputting it. 

According to the invention, since the 

25 recovery process is performed by selecting an 

information processing apparatus whose necessary 
recovery time including the time necessary for entering 
data still not backed up satisfies the predetermined 
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requested recovery time, it is possible to meet the 
needs for a relatively loose recovery of data still not 
backed up at the time of a failure by later inputting 
it- 

5 It should be further understood by those 

skilled in the art that although the foregoing 
description has been made on embodiments of the 
invention, the invention is not limited thereto and 
various changes and modifications may be made without 
10 departing from the spirit of the invention and the 
scope of the appended claims. 



